JB suggested I take a look and offer suggestions. Here are a few thoughts I had:

• could we call this alternatively with job_data rather than with a url? That avoids calling the API a second time to get the application_criteria after first calling it to get the job_details, which is unnecessary if they're both part of the same json response (as with GH). Other ATSs will require a new API call to get the application_questions anyway.
• I would put the logic that builds @fields in a separate method, so it can be easily swapped out for different ATSs
• likewise, fetch_json should go in a separate method. It's sometimes going to be more complicated than with GH. With ashby, for example, this request is a GraphQL query via a POST request with specific info in the request body and headers.
• just fyi, running FormFiller with GH jobs is a bit trickier if you're getting the questions via API, because mostly the API doesn't give you any useful locators other than the text of the question itself. I did some experimenting and verified that it's possible to get FormFiller to work using the text of the questions as locators, although it runs somewhat more slowly than if we get the element IDs via GetFormFields.

This is helpful context thanks Dan - noted on the updates to the Faraday helper and also calling with job_data instead - ideally we do this as you note (we'll need to build the URL carefully for Greenhouse in this case as perhaps we'll sometimes want to pass the additional params and sometimes not? Keen to discuss / hear thoughts)

Also a note on this - we can add further customisation into how Faraday makes the connection than what we're doing at the moment - think we might want to bring this in in future so just noting (e.g. custom user agent, proxy etc.)